Data authenticity assurance method, management computer, and storage medium

ABSTRACT

A data authenticity assurance method carried out by a management computer including: a first step of receiving the first data piece from the computer; a second step of selecting a plurality of second data pieces at predetermined intervals in chronological order from among the plurality of second data pieces held in the data holding part; a third step of performing an arithmetic operation for each of the hash values of the selected plurality of second data pieces; a fourth step of generating signature target data by combining the first data piece received from the computer with the hash values of the selected plurality of second data pieces; and a fifth step of generating a second data piece by assigning the digital signature to the signature target data by using the preset key, and holding the generated second data piece in chronological order sequentially in the data holding part.

INCORPORATION BY REFERENCE

The present application claims priority from Japanese patent applicationJP 2011-227308 filed on Oct. 14, 2011, the content of which is herebyincorporated by reference into this application.

BACKGROUND

This invention relates to a digital signature technology for long-termassurance of authenticity of log data or data that occurs in largequantity at any time.

Increasing attention is being drawn on technologies for long-termassurance of the authenticity of log data that occurs in large quantityat any time, such as: recording of linkage information on a resident IDsystem on which consideration is being advanced by the Japanesegovernment; and storage of access histories relating to use/utilizationof medical information and transaction data in financial systems.

There is a digital signature as a technology for assuring theauthenticity of electronic data, but the digital signature expires inthree to five years, which causes a problem when long-term storagethereof is set as a purpose. As a method for solving this problem, at atime of assigning a signature to every piece of data, a hash value iscalculated after it is confirmed that the first previous piece of signeddata has not been tampered, and the signature is assigned along withsignature target data. Therefore, all the pieces of data form a hashchain by including the hash value of the first previous piece of signeddata. By forming the hash chain, it is possible to link the pastsignature to the latest signature with the hash value, which allows theassurance of the past signature by using the latest signature. In otherwords, even when the signature expires, it is possible to assure theauthenticity of the past data by tracing the hash chain from data(hereinafter referred to as “trust point”) that is assured by anunexpired signature. In other words, the wording “tracing the hashchain” represents using the signed data forming the hash chain to repeatan operation for verifying that the first previous piece of signed datahas not been tampered by comparing the hash value of the first previouspiece of signed data included in the verified data with the hash valuecalculated from the first previous piece of signed data.

However, when the long-term assurance of the authenticity of a largequantity of log data is set as a purpose, assigning signatures to allthe pieces of log data increases a load on a computer. Further, when agiven piece of log data is tampered, the authenticity of the log dataearlier than the given piece is no longer assured. In addition, toverify the authenticity of specific log data, it is necessary to examineall the hash chains one by one from the trust point (log data with anunexpired signature) up to the specific log data, which raises a problemof increasing the load on the computer.

In order to solve those problems, in WO 2008/026238, there is discloseda method of reducing a frequency at which a signature is assigned to thedata forming the hash chain down to once every a plurality of pieces, tothereby reduce the load on the computer. At this time, a method ofsaving the hash value of the first previous piece of data to atamper-resistant apparatus is disclosed as a method of assuring that thefirst previous piece of data has not been tampered. In other words, itis possible to confirm that the first previous piece of data has notbeen tampered when the verification is performed by comparing the hashvalue saved to the tamper-resistant apparatus with the hash valuecalculated from the first previous piece of data.

Further, as the assurance of the authenticity of the log data earlierthan a given piece of log data performed when the given piece istampered, there is disclosed a method of forming hash values of aplurality of pieces of log data to have a tree-like hierarchicalstructure by combining the hash values to take a hash value of thecombined hash values, and limiting an influence range of tampering to aspecific range when a lower part of the tree is tampered.

SUMMARY

WO 2008/026238 discloses that a hash tree structure is created tothereby limit an influence range of tampering to a specific range.However, such a structure that the authenticity of a given node isassured by a node at a higher level than the given node is employed, andhence there is vulnerability to a loss of the authenticity of an entirehash tree caused when the hash value corresponding to the node at thetop level is tampered. Therefore, the object of maintaining theauthenticity of the hash chain even when a given piece of data istampered is solved only in a limited manner.

Further, WO 2008/026238 discloses that the hash value is generated afterthe hash values of the plurality of pieces of log data are combined whenthe hash tree structure is generated, but does not disclose a method ofassuring that a plurality of hash values thereof are not tampered. Forexample, it is conceivable to employ a method of saving the plurality ofpieces of log data to the tamper-resistant apparatus as well as savingthe first previous piece of log data to the tamper-resistant apparatus,but when consideration is given to handling of a large quantity of logdata, there is a fear that a capacity of the tamper-resistant apparatusmay be exceeded by saving all the plurality of pieces of log data to thetamper-resistant apparatus. The problem of the capacity can be solved byexecuting the same function as the tamper-resistant apparatus in asoftware manner, but in that case, the load on the computer becomesexcessive when the hash tree is generated. When a complicated hash chainis thus generated for a large quantity of log data, it is necessary toreduce the load on the computer.

Further, WO 2008/026238 has a problem in that, to confirm theauthenticity of specific past data, all the hash chains need to betraced back from the present to the specific past data, which requiresmuch time for calculation.

Therefore, this invention has been made in view of the above-mentionedcircumstances, and an object thereof is to quickly perform, in a digitalsignature technology for long-term assurance of authenticity of log dataor data that occurs in large quantity at any time: maintenance ofauthenticity of other pieces of data at a time when a given piece ofdata is tampered; and verification of specific log data. Another objectthereof is to reduce a load on a computer when a digital signature isgenerated.

A representative aspect of this invention is as follows. A dataauthenticity assurance method carried out by a management computercomprising a processor and a memory, comprising: carrying out signaturegeneration processing for generating a second data piece by assigning adigital signature to data, which is obtained by combining a first datapiece received from a computer with a hash value of at least one seconddata piece acquired from second data pieces held in a data holding partof the management computer, by using a preset key, and holding thegenerated second data piece in the data holding part; and carrying outsignature verification processing for verifying authenticity byintermittently tracing a plurality of hash chains based on a pluralityof second data pieces held in the data holding part and the second datapiece of a verification target, wherein: the carrying out of thesignature generation processing comprises: a first step of receiving thefirst data piece from the computer; a second step of selecting aplurality of second data pieces at predetermined intervals inchronological order from among the plurality of second data pieces heldin the data holding part; a third step of performing an arithmeticoperation for each of the hash values of the selected plurality ofsecond data pieces; a fourth step of generating signature target data bycombining the first data piece received from the computer with the hashvalues of the selected plurality of second data pieces; and a fifth stepof generating a second data piece by assigning the digital signature tothe signature target data by using the preset key, and holding thegenerated second data piece in chronological order sequentially in thedata holding part; and the carrying out of the signature verificationprocessing comprises: a sixth step of receiving the second data piece ofthe verification target; a seventh step of acquiring a second data piecethat is verifiable alone from the data holding part, and verifying thesecond data piece; and an eighth step of performing verification for thesecond data piece of the verification target to the second data piecethat is verifiable alone by sequentially comparing a hash value obtainedby the arithmetic operation from the second data piece with the seconddata piece including the hash value, and performing the verification byintermittently tracing the plurality of hash chains.

Further, the data authenticity assurance method, wherein the second stepcomprises selecting, by the management computer, from the first previoussecond data piece and the (n×2^(p−1))th previous second data piece, the(N×2^(p−1)) being a general term serving as a geometric progression of afirst term of N and a common ratio of 2, when the at least one seconddata piece is selected at the predetermined intervals in chronologicalorder.

Accordingly, according to one embodiment of this invention, in thedigital signature technology for the long-term assurance of theauthenticity of data that occurs in large quantity at any time, allsecond data pieces (for example, log records) have a plurality of hashvalues of the second data pieces each positioned a plurality of seconddata pieces before, to thereby form a plurality of hash chains.Therefore, even when a given second data piece is tampered, theauthenticity of another second data piece can be assured by another hashchain. At this time, the number of verification steps for the digitalsignature can be reduced by efficiently performing the verification ofthe second data piece positioned a plurality of second data piecesbefore, and the second data piece can be generated while reducing a loadon the computer imposed when the digital signature is generated.

Further, the hash chain for the second data piece positioned a pluralityof second data pieces before is created when the second data piece isgenerated, to thereby reduce the number of steps of the verificationprocess for the hash chain, and hence it is possible to verify thesecond data piece of a verification target at high speed. In addition,the processing for verifying whether or not the second data piecepositioned a plurality of second data pieces before has been tampered isperformed when the second data piece is generated, and hence thetampering of the second data piece can be discovered at an early stage.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a first embodiment of this invention, and is a blockdiagram illustrating an example of a data processing system.

FIG. 2 shows the first embodiment of this invention, and is a blockdiagram illustrating an example of functional components of the logmanagement server.

FIG. 3 shows the first embodiment of this invention, and is a blockdiagram illustrating an example of functional components of theapplication server.

FIG. 4 shows the first embodiment of this invention, and is a blockdiagram illustrating an example of a log management server andapplication server.

FIG. 5 shows the first embodiment of this invention, and is a diagramillustrating an example of a history of the signatures of the logrecords.

FIG. 6 shows the first embodiment of this invention, and is a diagramillustrating an example of a hash chain.

FIG. 7 shows the first embodiment of this invention, and is a flowchartillustrating an example of the processing performed by a log managementserver.

FIG. 8 shows the first embodiment of this invention, and is a diagramillustrating an example of tracing the log when high-speed verificationis performed.

FIG. 9 shows the first embodiment of this invention, and is a flowchartillustrating an example of the verification processing for thehigh-speed verification.

FIG. 10 shows a second embodiment of this invention, and is a diagramillustrating an example of tracing the hash chain when the high-speedverification.

FIG. 11 shows the second embodiment of this invention, and is aflowchart illustrating an example of the verification processing for averification route with the minimum number of times of verification.

FIG. 12 shows a third embodiment of this invention, and is a blockdiagram illustrating an example of log data processing performed in theinformation coordination system.

FIG. 13 shows the third embodiment of this invention, and is a flowchartillustrating an example of the information coordination processing.

FIG. 14 shows a fourth embodiment of this invention, and is a diagramillustrating a structure of the hash chain for visualizing the structureof the hash chain of the log record.

FIG. 15 shows the fourth embodiment of this invention, and is a diagramillustrating a structure of the hash chain for visualizing the structureof the hash chain of the log record.

FIG. 16 shows a fifth embodiment of this invention, and is a blockdiagram illustrating an example of a log management system.

FIG. 17 shows the fifth embodiment of this invention, and is a blockdiagram illustrating an example of functional components of the logmanagement client.

FIG. 18 shows the fifth embodiment of this invention, and is a flowchartillustrating an example of the log generating processing.

FIG. 19 shows the fifth embodiment of this invention, and is a flowchartillustrating an example of the log verification processing.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Now, embodiments of this invention are described with reference to FIG.1 to FIG. 9.

First, a configuration of a first embodiment of this invention isdescribed with reference to FIG. 1.

FIG. 1 is a block diagram illustrating an example of a data processingsystem to which the first embodiment of this invention is applied.

The data processing system according to the first embodiment includes anapplication server 102-1 to an application server 102-L (hereinafterreferred to collectively as “application server 102”) for providing acomputer of a user with a task application, a database, and the like, alog management server 101 for collecting logs from the applicationservers 102 and managing the logs, and a network 103 for coupling therespective servers to one another.

Next, respective apparatus included in the data processing systemillustrated in FIG. 1 are described.

First, the log management server 101 is described with reference to FIG.2. FIG. 2 is a block diagram illustrating an example of functionalcomponents of the log management server 101.

The log management server 101 includes a processing part 201 forgenerating a log record from log data sent from the application server102 and performing verification of the log record and determination ofauthenticity thereof in response to a request received from the user, astorage part 202 for storing the log record generated by the logmanagement server 101 and data such as a key necessary for processing,an input/output part 210 for receiving an input from the user or anadministrator, and a communication part 211 for receiving the log dataoutput from the application server 102. It should be noted that, in thefollowing description, the log output by the application server 102 isreferred to as “log data”, and the log processed by the log managementserver 101 in such a manner as described later is referred to as “logrecord”.

The processing part 201 includes a signature generation part 203 forassigning a signature to data obtained by combining the log data withthe hash value of the log record, a signature verification part 204 forverifying the signature of the log record, a hash value comparison part205 for performing the verification by comparing a given hash valueincluded in the log record with the log record relating to the givenhash value, a hash value generation part 206 for generating a hash valueby taking the hash value of the log record, and a control part 207 forcontrolling those parts.

The storage part 202 includes a log record holding part 208 for storinga log that has been subjected to signature processing and the like and asecret key/certificate holding part 209 for holding a secret key, acertificate, and a public key used for performing signature generationand verification. It is also conceivable that the secret key and thecertificate are saved to, for example, a tamper-resistant apparatus.

It should be noted that, although not shown, the signature verificationpart 204 may include the hash value comparison part 205, and thesignature generation part 203 may include the hash value generation part206.

Next, the application server 102 is described with reference to FIG. 3.FIG. 3 is a block diagram illustrating an example of functionalcomponents of the application server 102.

The application server 102 includes a processing part 301 for executingan application and outputting a log, a storage part 302, an input/outputpart 307 for receiving an input from the user, and a communication part308 for communicating to/from the log management server 101 and anotherapplication server.

The processing part 301 includes a log output processing part 303 forperforming processing for sending the log generated by the applicationserver 102 to the log management server 101, an application processingpart 304 for performing execution of the application and the like, and acontrol part 305 for controlling those parts.

The storage part 302 includes an application data holding part 306 forstoring data necessary to execute the application.

It should be noted that the processing parts 201 and 301 of the logmanagement server 101 and the application server 102, respectively,exemplified in FIG. 2 and FIG. 3 can be embodied by, for example, a CPU401 executing a predetermined program loaded into a memory 402 on ageneral electronic computer including, as illustrated in FIG. 4, the CPU401, the memory 402, an external storage apparatus 404 such as a harddisk drive, a communication apparatus 403 for performing communicationsto/from another apparatus through the Internet or the network 103, aninput apparatus 405 such as a keyboard and a mouse, an output apparatus406 such as a display apparatus and a printer, a reader apparatus 407for reading information from a portable storage medium 408, and aninternal communication line 409 for coupling those respective apparatusto one another.

The above-mentioned respective apparatus can be realized by using ageneral computer including the CPU 401 and a storage apparatus or usingprograms or hardware having functions equivalent to those of the generalcomputer.

Further, each of the above-mentioned processing parts can be realized bythe CPU 401 executing predetermined programs loaded into the memory 402from the external storage apparatus 404. In other words, thecommunication parts 211 and 308 are realized by the CPU 401 using thecommunication apparatus 403. The input/output parts 210 and 307 arerealized by the CPU 401 using the input apparatus 405, the outputapparatus 406, and the reader apparatus 407. Further, the storage parts202 and 302 are realized by the CPU 401 using the memory 402 and theexternal storage apparatus 404. Further, the processing parts 201 and301 are realized as processes of the CPU 401.

Those programs may be stored in the memory 402 or the external storageapparatus 404 within the above-mentioned electronic computer in advance,or may be introduced from the detachably attachable storage medium 408that can be used by the above-mentioned electronic computer or fromanother apparatus through a communication medium (such as the network103; or a carrier wave or a digital signal that propagates thereon) asthe need arises.

Further, this embodiment is described as being realized by suchconfigurations as illustrated in FIG. 1 to FIG. 3, but this invention isnot limited to those configurations. Not only the log management server101 but also the application server 102 may have a function of managingthe log record.

Next, with reference to FIG. 5, a detailed description is made of thelog record held in the log record holding part 208 of the log managementserver 101. The description of this embodiment is directed to a case ofincluding the third previous log record and the sixth previous logrecord as examples of the log record positioned a plurality of logrecords before. It should be noted that those log records are generatedby the signature generation part 203 of the log management server 101.

One log record 501 includes log data 502 serving as a body of the logdata transmitted from the application server 102, a data ID 503 servingas a unique ID indicating the log data 502, a hash value 504 of thefirst previous log record, an ID₁ 505 for concatenation serving as aunique ID indicating the hash value 504 of the first previous logrecord, a hash value 506 of the third previous log record, an ID₂ 507for concatenation serving as a unique ID indicating the hash value ofthe third previous log record, a hash value 508 of the sixth previouslog record, an ID₃ 509 for concatenation serving as a unique IDindicating the hash value of the sixth previous log record (the ID₁ forconcatenation to the ID₃ for concatenation are hereinafter referred tocollectively as “ID for concatenation”), and a signature 510 obtained byassigning a digital signature to the respective fields 502 to 509.

The a-th log record is hereinafter referred to as “log record Sa”.Further, a specific description is made below by taking an example of alog record S8. The log record S8 includes “M8” as the log data 502, “8”as the data ID 503 of the log data M8, “H(S7)” (“H(S7)” indicates thehash value calculated from the log record S7. The same applies in thefollowing description) as the hash value 504 of the first previous logrecord, “7” as the ID₁ for concatenation, “H(S5)” as the hash value 506of the third previous log record, “5” as the ID₂ for concatenation,“H(S2)” as the hash value 508 of the sixth previous log record, “2” asthe ID₃ for concatenation, and the signature 510 obtained as a result ofassigning the signature to the log data M8, H(S7), H(S5), and H(S2).

The signature generation part 203 of the log management server 101assigns the digital signature to the record of the log data receivedfrom the application server 102 after subjecting each of the hash value504 of the first previous (immediately previous) log record and the hashvalue 506 of the third previous log record to an arithmetic operationand replicating the hash value 508 of the sixth previous log record fromthe third previous log record. Further, the signature generation part203 assigns the IDs for concatenation to the first previous, the thirdprevious, and the sixth previous log records.

It should be noted that the log records illustrated in FIG. 5 illustratea history of the signatures 510 of the log records generated by the logmanagement server 101 from the log data on specific data subjected tothe processing by the application server 102. The log record holdingpart 208 stores such a history of the signature 510 of the log record asillustrated in FIG. 5 for each piece of data processed by theapplication server 102.

Next, FIG. 6 illustrates a structure 601 of a hash chain for visualizinga structure of a hash chain of the log record exemplified in FIG. 5. Asillustrated in FIG. 5, one log record includes the hash values of thefirst previous, the third previous, and the sixth previous log records,and as illustrated in FIG. 6, all the log records each form chains (hashchains) of the log records by the hash values of the first previous, thethird previous, and the sixth previous log records. In other words, aplurality of hash chains are generated from one log record.

Next, a description is made of an example of processing performed by thedata processing system according to this embodiment. First, withreference to FIG. 7, a description is made of an example of a generationmethod for the log record. FIG. 7 is a flowchart illustrating an exampleof the processing performed by the control part 207 of the logmanagement server 101 when generating one of the log records illustratedin FIG. 5. Here, the description is made by taking an example ofprocessing for generating a log record S11 illustrated in FIG. 5. Itshould be noted that the processing of FIG. 7 is executed at apredetermined timing such as when the log management server 101 receivesthe log data.

The control part 207 starts the processing by receiving log data M11from the application server 102. First, the log data M11 acquired fromthe communication part 211 is saved to the log record holding part 208as a new log record (Step 701). It should be noted that the new logrecord may be generated by the signature generation part 203.

Subsequently, the signature verification part 204 verifies a log recordS10 serving as the first previous log record saved to the log recordholding part 208 (Step 702). Specifically, the signature verificationpart 204 acquires the public key from the certificate saved to thesecret key/certificate holding part 209 in advance, acquires datadecrypted by applying the public key to the signature 510 of the logrecord S10, and compares the acquired data with the hash value of thelog record S10. The signature verification part 204 acquires log dataM10 and hash values H(S9), H(S7), and H(S4) from the signature 510subjected to the digital signature with the public key, and compares thelog data 502 of the log record S10 with the hash values 504, 506, and508, to thereby verify the authenticity of the log record S10. In otherwords, when the log data and the hash values included in the signature510 subjected to the digital signature are equal to the log data 502 andthe respective hash values 504, 506, and 508 of the log record S10,respectively, it is assured that the log record S10 is valid data thathas not been tampered. It should be noted that the signatureverification part 204 may perform the verification for the hash valuesincluded in the signature 510 subjected to the digital signature and therespective hash values 504, 506, and 508 of the log record S10.

When it is confirmed as a result of the verification that the log recordS10 has not been tampered (“SUCCEEDS IN VERIFICATION” in Step 702), thesignature verification part 204 generates the hash value of the logrecord S10 by the hash value generation part 206 of the signaturegeneration part 203, and saves the hash value to the log record holdingpart 208 along with the data ID 503 of “10” (Step 704). Therefore, afterthe signature verification part 204 verifies that the log record S10 hasnot been tampered, the signature generation part 203 can add the hashvalue of the first previous log record S10 to the hash chain of the logrecord S11. On the other hand, when the first previous log record S10has been tampered or erased, the procedure advances to Step 703, and thesignature verification part 204 carries out error processing asdescribed later.

Subsequently, the signature verification part 204 verifies the logrecord S8 serving as the third previous log record saved to the logrecord holding part 208 in the same manner as in the above-mentionedStep 702, and when a verification result is correct (“SUCCEEDS INVERIFICATION” in Step 705), the hash value generation part 206 generatesthe hash value of the log record S8, and saves the hash value to the logrecord holding part 208 along with the ID₂ 507 for concatenation of “8”(Step 707). Therefore, after the signature verification part 204verifies that the log record S8 has not been tampered, the hash valuegeneration part 206 can add the hash value of the third previous logrecord S8 to the hash chain of the log record S11. On the other hand,when the third previous log record S8 has been tampered or erased, theprocedure advances to Step 706, and the signature verification part 204carries out the error processing as described later.

Further, a hash value H(S5) of the sixth previous log record is alsosaved in the third previous log record S8, and hence the hash valuegeneration part 206 replicates the hash value H(S5), and saves the hashvalue to the log record holding part 208 along with the ID₃ 509 forconcatenation of “5” (Step 708). At this time, it was already verifiedin Step 705 that the third previous log record S8 has not been tampered,and hence it is also already verified that H(S5) included in the logrecord S8 as a part thereof has not been tampered.

Subsequently, the signature generation part 203 assigns the digitalsignature to the log data (message) M11 acquired from the applicationserver 102, hash values H(S10), H(S8), and H(S5), and the data ID 503 of“11” and IDs for concatenation of “10”, “8”, and “5” that are IDs ofthose hash values. In other words, the signature generation part 203uses the secret key saved in the secret key/certificate holding part 209to calculate a signature value for the log data. Subsequently, thesignature generation part 203 saves the obtained signature 510 to thelog record holding part 208 (Step 709).

By the processing of the above-mentioned Steps 701 to 709, the logmanagement server 101 generates the log record S11 from the received logdata M11 by assigning the digital signature to the hash values of thelog records S10, S8, and S5 with the secret key, and stores the logrecord S11 in the log record holding part 208.

In the above-mentioned processing, an example in which (N×2^(p−1))thprevious log record is acquired as a method of selecting the log recordpositioned a plurality of log records before is described.

In the expression, N represents a constant of a natural number, prepresents a variable of a natural number assuming values of 1 to n, andn represents a value indicating how many hash values of log records eachpositioned a plurality of log records before are to be acquired. Itshould be noted that, in the example of FIG. 5 described above, theexample in which the immediately previous log record and n (N×2^(p−1))thprevious log records are acquired.

The verification that each log record has not been tampered and thecalculation of the hash value can be performed based on the one-timecomparison of the hash values and the replication of the hash value, andhence a load of the arithmetic operation on the log management server101 imposed when the log record is generated is alleviated.

The specific description is made on the assumption that N=3, p={1, 2, 3,4}, and n=4. The log records each positioned a plurality of log recordsbefore are selected at this time as the third previous log record whenp=1, the sixth previous log record when p=2, the twelfth previous logrecord when p=3, and the twenty-fourth previous log record when p=4, andall the log records have the hash values of the third previous, thesixth previous, the twelfth previous, and the twenty-fourth previous logrecords. To generate a new log record, after verifying the thirdprevious log record by the signature verification part 204, thesignature generation part 203 acquires and replicates the hash value ofthe sixth previous log record (which means another third previous logrecord for the third previous log record) included in the third previouslog record, and compares the acquired hash, value with the hash valuecalculated from the sixth previous log record, to thereby verify thesixth previous log record. The sixth previous log record verified by thesignature verification part 204 includes the hash value of the twelfthprevious log record (which means another sixth previous log record forthe sixth previous log record), and hence the signature generation part203 acquires and replicates the hash value of the twelfth previous logrecord, and compares the acquired hash value with the hash valuecalculated from the twelfth previous log record, to thereby verify thetwelfth previous log record. The twelfth previous log record verified bythe signature verification part 204 includes the twenty-fourth previouslog record (which means another twelfth previous log record for thetwelfth previous log record), and hence the signature generation part203 replicates the hash value thereof, and brings the processing to anend.

In this manner, the signature generation part 203 can generate the logrecord including the hash values of the third previous, the sixthprevious, the twelfth previous, and the twenty-fourth previous logrecords by performing signature verification processing once, the hashvalue comparison processing twice, and replication processing fourtimes.

On the other hand, in the error processing executed in Step 703 and Step706 by the signature verification part 204, an alert indicating that theverification processing for the log record has failed and a verificationtarget log record may have been tampered or erased is issued to theuser. For example, the data ID 503 of the tampered log record is outputto the computer used by the user along with an error message, to bedisplayed on the output apparatus 406 of the computer.

As described above, in the first embodiment of this invention, togenerate a new log record of specific log data, a plurality of logrecords relating to the specific log data are sorted in chronologicalorder of the signature 510, and the immediately previous log record isselected along with n log records at predetermined intervals of N logrecords in descending chronological order of the signature 510. Then,the log management server 101 performs an arithmetic operation for eachof the hash values of the immediately previous log record and the N-thprevious log record. Then, as the hash value of the log record earlierthan the N-th previous log record (log record positioned N×(2 or more)log records before), the hash value stored in the N-th previous logrecord is replicated. The log management server 101 stores n+1 hashvalues in the new log record, but actually performs the arithmeticoperation only twice for the hash values of the immediately previous logrecord and the N-th previous log record while only replicating the otherhash values, which can reduce the load of the arithmetic operation.

In other words, to generate a new log record, the log management server101 selects a plurality of log records at predetermined intervals inchronological order of the digital signature 510, performs thearithmetic operation for the hash value of the latest log record amongthe selected plurality of log records, and performs the arithmeticoperation for the hash value of the immediately previous log record.Then, the log management server 101 replicates the hash values held inthe respective log records as the hash values of the selected pluralityof log records other than the latest log record.

Next, with reference to FIG. 8 and FIG. 9, a description is made of anexample of a high-speed verification method for a specific log record.Here, the specific data represents the log record for which averification request has been received by the input/output part 210 fromthe computer of the user or the log record for which a verificationrequest has been received from the input apparatus 405.

FIG. 8 is a diagram illustrating an example of tracing the log whenhigh-speed verification is performed. FIG. 8 illustrates a high-speedverification route 801 exemplifying the shortest route for verifying thelog record S1 when the log record S11 is set as a trust point. At thistime, it is assumed that the signatures of the log records S1 to S10have already expired. Here, as an example, an example in which theverification is performed in three steps is described. In this example,by performing the comparison and verification of the signature 510 andthe hash value for the hash value of the sixth previous log record S5which is the earliest one of the hash values included in the log record,it is possible to omit the number of steps compared to the case oftracing the hash chains one by one. At this time, a range of omission isgradually narrowed down by performing the comparison of the hash valuefor the second earliest hash value when the earliest hash value isearlier than the specific data and performing the comparison for thethird earliest hash value when the second earliest hash value is earlierthan the specific data, thereby realizing the verification of theauthenticity of the specific data with the least number of steps.

In the example of FIG. 8, for the hash value of the sixth previous logrecord S5 which is the earliest one of the hash values included in thelog record S11, the signature verification part 204 calculates andverifies the hash value H(S5) included in the log record S11 and thehash value of the log record S5.

Subsequently, the signature verification part 204 calculates theearliest hash value H(S2) included in the log record S5 and the hashvalue of the log record S2, and performs the verification thereof in thesame manner as described above.

Finally, the signature verification part 204 calculates the earliest(immediately previous) hash value H(S1) included in the log record S2and the hash value of the log record S1, and performs the verificationthereof in the same manner as described above.

By performing the verification three times as described above, thesignature verification part 204 can assure that the log record S11 isauthenticated data on the log record S1. Therefore, without the need totrace back all the log records S1 to S10, the log management server 101can quickly perform the verification by tracing back the log records S5and S2 for the authenticity of the log record S11 for which a requesthas been made.

FIG. 9 is a flowchart illustrating an example of the verificationprocessing for the high-speed verification route 801 of FIG. 8 performedby the signature verification part 204. The detailed description is madebelow with reference to FIG. 9.

First, the log record to be verified is acquired from the input/outputpart 210, and the trust point is selected. The trust point to beselected is a log record that has an unexpired signature and is closestto the verification target log record. In this case, it is assumed thatthe signatures of the log records S1 to S10 illustrated in FIG. 8 haveexpired, and hence the log record S11 is selected as the trust point(Step 901).

Subsequently, the signature of the trust point is verified by thesignature verification part 204 (Step 902). When the trust point isverified, a variable x that holds the data ID of the verified log recordis initialized to the data ID of the trust point (Step 904). Accordingto the example of FIG. 8, the variable x is substituted with “11”. Fromthat point on, Step 906 to Step 908 are repeated until the variable xreaches the ID of the verification target (ID of 1 according to theexample of FIG. 8) (Step 905).

On the other hand, when the verification of the log record fails in Step902, the signature verification part 204 advances to Step 903 to executethe error processing described later.

The signature verification part 204 selects, among IDs for concatenationincluded in a log record Sx, and are the same ID for concatenation asthe data ID of the verification target log record or the earliest ID forconcatenation among IDs later than that of the verification target logrecord, and substitutes the variable x therewith (Step 906).Specifically, the ID for concatenation of the hash value H(S5)satisfying the above-mentioned condition among the hash values includedin the log record S11 illustrated in FIG. 5 is “5”, and hence thevariable x is substituted with “5”.

Subsequently, the hash value comparison part 205 compares the hash valueH(S5) with the calculated hash value of the log record S5, to therebyperform partial verification of the structure 601 of the hash chainillustrated in FIG. 5 (Step 907). Therefore, the signature verificationpart 204 assures that the log record S5 has not been tampered.

The log record S5 is not the verification target log record, and henceSteps 906 to 908 are repeated. In other words, the hash value H(S2)satisfying the above-mentioned condition among the hash values includedin the log record S5 is compared with the calculated hash value of thelog record S2, and further partial verification of the structure 601 ofthe hash chain illustrated in FIG. 6 is performed. The log record S2 isnot the verification target log record, and hence the hash value H(S1)satisfying the above-mentioned condition among the hash values includedin the log record S2 is compared with the calculated hash value of thelog record S1, and the partial verification of the hash chain isperformed, which brings the verification of the verification target logrecord to an end.

In the error processing of Step 903, the signature verification part 204issues, to the user, an alert indicating that the data of the trustpoint may have been tampered or erased. For example, the data ID 503 ofthe tampered log record is transmitted to the computer of the user alongwith the error message, to be displayed on the output apparatus 406 ofthe computer.

In this error processing of Step 903, the procedure returns to Step 901to select a new trust point. At this time, it is assumed that the newtrust point to be selected is a log record that has an unexpiredsignature and is closest to the verification target log record, but isnot a log record that has caused an error. After that, theabove-mentioned processing of Step 902 and the subsequent steps isexecuted.

Further, when the verification of the log record fails in Step 907, thesignature verification part 204 advances to Step 908 to execute theerror processing described later.

In the error processing of Step 908, an alert that the verificationprocessing has failed and the log record may have been tampered orerased is issued to the user. For example, the data ID 503 of thetampered log record is transmitted to the computer of the user alongwith the error message, to be displayed on the output apparatus 406 ofthe computer.

Subsequently, in this error processing of Step 903, the verification ofthe specific data may be continued in another verification route. Forexample, it is also possible to select a verification route other thanthe high-speed verification route 801 illustrated in FIG. 8. Forexample, as a method of selecting another verification route, it isconceivable to select a verification route caused from another hashvalue included in the verified log record or a verification route causedfrom another hash value included in the log record that has assured theverified log record.

As an example, a description is made of a case where the verification ofthe data of the log record S5 has failed in the verification processingfor the above-mentioned specific data. The signature verification part204 first selects the log record S11 as the trust point (Step 901). Thesignature verification part 204 verifies the log record S11 of theselected trust point (Step 902), and substitutes the variable x with“11” (Step 904). “11” is not the data ID of the verification target logdata (Step 905), and hence the variable x is substituted with the ID of“5” satisfying the condition of being, among the IDs for concatenationfor the hash values included in the log record S11, the same ID forconcatenation as the data ID of the verification target the log recordor the earliest ID for concatenation among the IDs later than that ofthe verification target log record (Step 906). Subsequently, the hashvalue H(S5) and the log record S5 are verified by the hash valuecomparison part 205 (Step 205). Here, the verification of the log recordS5 fails as described above, and hence the error processing (Step 908)is performed to select the alert to be issued to the user and anotherverification route. In this example, of other hash values H(S8) andH(S10) that are included in the log record S11, the hash value H(S8)closer to the verification target log record S1 is selected as a newverification route. Subsequently, the hash value H(S8) and the logrecord S8 are verified by the hash value comparison part 205 (Step 908).The log record S8 can be verified, and hence the above-mentioned normalverification processing for the specific data is performed to repeatStep 906 to Step 908. Specifically, the hash value H(S2) is selectedfrom among the hash values included in the log record S8 (Step 906), andthe hash value H(S2) and the hash value calculated from the log recordS2 are verified by the hash value comparison part 205 (Step 908). Thehash value H(S1) included in the verified log record S2 and the hashvalue calculated from the log record S1 are verified by the hash valuecomparison part 205, and the verification of the log record S1 isbrought to an end. In this manner, even when a given piece of data hasbeen tampered or erased, by using the hash value of another log recordincluded in the log record of the trust point, it is possible to verifythe log record even when the verification has failed, and it is possibleto positively verify the authenticity.

The first embodiment of this invention has been described above.According to this embodiment, in a digital signature technology forlong-term assurance of authenticity of data that occurs in largequantity at any time, all the log records have a plurality of hashvalues of the log record positioned a plurality of log records before,to thereby form a plurality of hash chains.

Therefore, even when a given log record has been tampered, theauthenticity of the other log records can be assured by another hashchain.

At this time, the number of verification steps for the digital signatureis reduced by efficiently performing the verification of the log recordpositioned a plurality of log records before, to thereby be able togenerate the log record while reducing a load on the computer imposedwhen the digital signature is generated.

Further, the hash chain for the log record positioned a plurality of logrecords before is created when the log record is generated, to therebyreduce the number of steps of the verification processing for the hashchain, and hence it is possible to realize the high-speed verificationof the specific data.

In addition, the processing for verifying whether or not the log recordpositioned a plurality of log records before has been tampered isperformed when the log record is generated, and hence the tampering ofthe log record can be discovered at an early stage.

It should be noted that this invention is not limited to theabove-mentioned embodiment, and various modifications can be made withinthe scope of the gist thereof.

In the first embodiment, the third previous and the sixth previous logrecords are acquired, but it can be arbitrarily set how many hash valuesof the log record positioned how many log records before are taken,which may be the N-th previous (N is a constant) log record or may bethe log record positioned a random number of log records before. Inother words, a plurality of hash values may be acquired from the logrecord positioned a plurality of log records before. Further, it is alsopossible to set so that the hash value of the log record positioned afixed time before is taken. When the hash value of the log record isacquired arbitrarily as described above, as a method of confirming thatthe log record at a time of log generation has not been tampered andbuilding the verification route up to the specific data in theverification of the specific data, an optimal route can be calculated byapplying a well-known or publicly-known graph theory.

Further, this embodiment can be realized by such configurations asillustrated in FIG. 1 to FIG. 3, but this invention is not limited tothe above-mentioned configurations. Not only the log management server101 but also the application server 102 may be provided with a functionof generating and managing the log record illustrated in FIG. 5.

In addition, in the above-mentioned embodiment, the application server102 sends the log data to the log management server 101 each time a logoccurs, but may be able to send, for example, a file obtained bycombining log data that occurs in one day to the log management server101. In this case, there is a fear that the file may be tampered beforebeing sent to the log management server 101, and hence as acountermeasure thereto, it is conceivable to provide the applicationserver 102 with the function of generating the hash chain or to use atime stamp. As a method of processing the sent file by the logmanagement server 101, it is conceivable to employ a method of creatingthe hash chain from the log record within the file or a method ofcreating the hash chain on a file-to-file basis by handling the fileitself as the log data.

Further, the description of this embodiment is directed to the examplein which the log data is used as the data to be verified, but thisembodiment can be applied to the computer system for subjectingelectronic data to the digital signature.

FIG. 10 and FIG. 11 illustrate an example of a high-speed verificationmethod for a specific log record according to a second embodiment ofthis invention. This second embodiment has a feature in that the trustpoint having the minimum number of times of verification of the hashchain is selected, the selected trust point and the hash chain of theverification target are verified, and the hash chain used for theverification is further output. In the first embodiment, the log recordthat has an unexpired signature and is closest to the verificationtarget log record is selected as the trust point, but in thisembodiment, a log record that has an unexpired signature and has asignature having the minimum number of times of verification of the hashchain is selected as the trust point.

This embodiment relates to a method obtained by changing the high-speedverification method described with reference to FIG. 8 and FIG. 9 in thefirst embodiment, and it is assumed that the log record is generated bythe system configuration and the generation method for the log recordthat are described with reference to FIG. 1 to FIG. 7.

At this time, the trust point is a log record having an unexpiredsignature, and a normal electronic certificate normally has an expiryperiod of approximately five years, which means that a plurality of logrecords having an unexpired signature (trust points) exist at a giventime point. For example, when an electronic certificate having an expiryperiod of five years is used, all the log records during five years atmaximum can be set as the trust points.

FIG. 10 is a diagram illustrating an example of tracing the hash chainwhen the high-speed verification is performed in this embodiment. InFIG. 10, as an example, it is assumed that the log records S11 to S13are the log records having an unexpired signature, and the log record S1is the verification target log record. At this time, a set of logrecords that can be the trust points such as the log records having anunexpired signature are stored in the storage part 202 illustrated inFIG. 2, and stored in, for example, a DB or a file.

A processing method therefor is described below. In this embodiment,without first determining the trust point, the trust points are selectedin parallel with the verification of the hash chain. Specifically, theexpiry periods of the signatures of the log records S7 and S13 coupledto the log record S1 by the hash chain are examined in parallel with theverification of the hash chain of the log records S7 and S13 coupled tothe verification target log record S1 by the hash chain, and when thesignature to be the trust point is found, the tracing of the hash chainis brought to an end, to set the signature as the trust point. Then, thesignature verification of the trust point is performed, and it isexamined whether or not the verification target log record S1 is coupledto the trust point by the hash chain and the verification target logrecord S1 has not been tampered.

As described above, the verification of the verification target logrecord S1 is finished by performing hash value verification twice whenthe verification is performed by using the log record S13 as the trustpoint among the log records S11 to S13.

FIG. 11 is a flowchart illustrating an example of the verificationprocessing for a verification route 1001 with the minimum number oftimes of verification illustrated in FIG. 10, which is performed by thesignature verification part 204. The detailed description is made belowwith reference to FIG. 11.

First, the log record to be verified is acquired from the input/outputpart 210, and the ID of the acquired log record is substituted into thevariable x that holds the ID of the verification target log record (Step1101). Specifically, x is substituted with “1”.

Subsequently, the signature verification part 204 calculates the logrecord having a hash value of Sx, and the ID of the latest log recordamong the calculated log records is substituted into a variable y thatholds the ID of a comparison target log record (Step 1102).Specifically, the log records S2, S4, and S7 have the hash value of theverification target log record (S1), and the ID “7” for concatenation ofthe latest log record S7 thereof is substituted into the variable y.

Subsequently, the hash value comparison part 205 compares the hash valueH (Sx) included in a log record Sy with the calculated hash value of thelog record Sx, and performs the partial verification of the structure601 of the hash chain illustrated in FIG. 6 (Step 1103). Specifically,the hash value H(S1) included in the log record S7 is compared with thecalculated hash value of the log record S1. Therefore, the signatureverification part 204 confirms that the log record S1 has not beentampered. Subsequently, the signature verification part 204 examineswhether or not the log record Sy is registered as the trust point, andwhen the log record Sy is not registered, substitutes the variable xwith the variable y, to advance to Step 1102. Specifically, the logrecord S7 is not registered as the trust point, and hence the variable xis substituted with the ID “7” for concatenation of the log record S7,the latest log record S13 among the log records S8, S10, and S13 havingthe hash value of the log record S7 is substituted into the variable y(Step 1102), and the hash value H(S7) included in the log record S13 iscompared with the calculated hash value of the log record S7 (Step1103).

Subsequently, the signature verification part 204 confirms that the logrecord S113 is registered as the trust point, and advances to Step 1106to perform the signature verification of the log record S13. When thesignature verification of the log record S13 is successful, it can beconfirmed that the hash value H(S7) included in the log record S13 hasnot been tampered. When all the above-mentioned processing proceduresare successful, the signature verification of the log record S13selected as the trust point and the verification of the hash chain fromthe trust point up to the verification target log record S1 have beenconfirmed.

Subsequently, the signature verification part 204 presents theverification result and a list of the log records used for theverification to the user, and brings the verification of theverification target log record to an end (Step 1108). The list of thelog records used for the verification represents, specifically, the logrecords S1, S7, and S13, and the data IDs 503 of the series of logrecords are presented to the user. It should be noted that the user mayacquire the series of log records from the log record holding part 208by using the data IDs 503 of the series of log records as keys.

It should be noted that, in the error processing of Step 1104 and Step1107, the signature verification part 204 issues, to the user, an alertindicating that the log record Sy recorded in the storage part 202 mayhave been tampered or erased. For example, the data ID 503 of thetampered log record is transmitted to the computer of the user alongwith the error message, to be displayed on the output apparatus 406 ofthe computer.

In this error processing of Step 1104 and Step 1107, the verification ofthe specific data may be continued in another verification route. Forexample, it is also possible to select a verification route other thanthe verification route 1001 with the minimum number of times ofverification illustrated in FIG. 10. For example, as a method ofselecting another verification route, it is conceivable to select averification route caused from another hash value included in theverified log record or a verification route caused from another hashvalue included in the log record that has assured the verified logrecord.

The second embodiment of this invention has been described above.According to this embodiment, by selecting an optimal trust point fromamong a plurality of trust points, the number of times of verificationof the hash value can be minimized, and it is possible to perform theverification at higher speed than the method of selecting the earliesttrust point as described in the first embodiment.

Further, by presenting the list of the log records used for theverification to the user, an evidence of the verification result can beprovided to a third party. The user can acquire the series of logrecords included in the presented list of the log records from the logrecord holding part 208, and can provide the third party therewith.Without having to access the log management server 101, the third partycan verify the authenticity of the verification target log record byusing the list of the log records provided by the user. In other words,by using evidence information provided by the user, the third party canconfirm the authenticity of the verification target log record byitself.

It should be noted that, in this second embodiment, the case where thehash values of the third previous and the sixth previous log records areincluded is assumed, but it can be arbitrarily set how many log recordseach positioned how many log records before are included, and by a setmethod, the trust point having the minimum number of times ofverification of the hash chain can be selected. As an example of aselection method, a well-known or publicly-known graph theory may beapplied.

Next, with reference to FIG. 12 and FIG. 13, a configuration of a thirdembodiment of this invention is described. This embodiment has a featurein that the data processing system described in the first and secondembodiments is applied to an information coordination system.

The information coordination system is a system for performing relaywhen information relating to a given person or an organization such as acompany is exchanged between different organizations such as aninformation query system and an information providing system. Forexample, when the information query system and the information providingsystem manage the given person or the organization such as the companyby different IDs, conversion is performed from the ID of the informationquery system to the ID of the information providing system, to relayinformation coordination.

The information exchanged in the information coordination systemincludes much sensitive information relating to the person or theorganization such as the company, and hence it is necessary to save theinformation on the information query system and the informationproviding system that are involved in the processing, a kind ofexchanged personal information, and the like as audit trails, and theaudit trails of the information coordination are archived in a logmanagement server as the log data.

In this embodiment, the data processing system described with referenceto FIG. 1 to FIG. 3 in the first embodiment is applied to theinformation coordination system, the log record described with referenceto FIG. 5 to FIG. 7 is generated, and the high-speed verification can beperformed by the processing described with reference to FIG. 8 and FIG.9, or in the second embodiment.

FIG. 12 is a block diagram illustrating an example of log dataprocessing performed in the information coordination system to which thethird embodiment of this invention is applied.

The information coordination system, the information query system, andthe information providing system are coupled to one another through thenetwork 103 such as the Internet or a broadband WAN. The informationcoordination system includes the log management server 101 and aninformation relay apparatus 1201, and the log management server 101 andthe information relay apparatus 1201 are coupled to each other throughan intra-organization network 1202. The information query system and theinformation providing system include information coordination apparatus1203 ₁ and 1203 _(N) (hereinafter referred to collectively as“information coordination apparatus 1203”) and log management servers1204 ₁ to 1204 _(N) (hereinafter referred to collectively as “logmanagement server 1204”), and the information coordination apparatus1203 ₁ and 1203 _(N) and the log management servers 1204 ₁ to 1204 _(N)are coupled to each other through intra-organization networks 1202 ₁ to1202 _(N), respectively.

Next, respective apparatus included in the information coordinationsystem illustrated in FIG. 12 are described. The information relayapparatus 1201 and the information coordination apparatus 1203 have thesame configuration as that of the application server 102. In otherwords, processing relating to the information coordination is performedby the application processing part 304, data to be set as the audittrail of the information coordination is output by the log outputprocessing part 303.

Next, an example of the log data processing performed in the informationcoordination system according to this embodiment is described withreference to FIG. 13. The information coordination apparatus 1203 of theinformation query system sends an information coordination request tothe information relay apparatus 1201 at a timing at which an informationcoordination start instruction is received from an operator or the likeof the information coordination apparatus 1203 or other such timing(Step S1301). The information query system that has sent the informationcoordination request outputs a record thereof to the log managementserver 1204 (Step S1302), and the log management server 1204 performsthe processing of FIG. 7 to generate a signature to the record andarchive the record (Step S1303).

The information relay apparatus 1201 that has received the informationcoordination request performs information relay processing for an IDindicating a person or an organization of a coordination target by, forexample, converting the ID from an ID used in the information querysystem into an ID used in the information providing system (Step S1304).Then, the information relay apparatus 1201 transmits the informationcoordination request to the information coordination apparatus 1203 ofthe information providing system (Step S1305), and outputs a record ofthe processing results of Step S1304 and Step S1305 to the logmanagement server 101 (Step S1306). The log management server 101performs the processing of FIG. 7 to generate the signature to therecord and archive the record (Step S1307).

The information coordination apparatus 1203 of the information providingsystem that has received the information coordination request performsprocessing such as generation of information to be transmitted inresponse to the information coordination request (Step S1308), andtransmits a result thereof to the information query system (Step S1309).The information coordination apparatus 1203 outputs the log data on theresults of the processing of Step S1308 and Step S1309 to the logmanagement server 1204 (Step S1310), and the log management server 1204performs the processing of FIG. 7 to generate the signature thereto andarchive the log data (Step S1311).

The information coordination apparatus 1203 of the information querysystem that has received the requested information outputs a receptionresult to the log management server 1204 (Step S1312), and the logmanagement server 1204 performs the processing of FIG. 7 to assign thesignature thereto and archive the reception result (Step S1313). Inaddition, the information coordination apparatus 1203 of the informationquery system sends the reception result to the information relayapparatus (Step S1314), and outputs a record of a result of theprocessing of Step 1314 to the log management server 1204 (Step 1315),while the log management server 1204 performs the processing of FIG. 7to generate the signature to the record and archive the record (Step1316).

Subsequently, the information relay apparatus 1201 that has received thereception result outputs a result of the reception processing to the logmanagement server 101 (Step S1317), and the log management server 101performs the processing of FIG. 7 to generate the signature thereto andarchive the result (Step 1318).

Further, the information providing system that has sent the requestedinformation in Step S1309 transmits a transmission result to theinformation relay apparatus (Step S1319), and outputs a record of aresult thereof to the log management server 1204 (Step S1320), while thelog management server 1204 performs the processing of FIG. 7 to assignthe signature to the log and archive the log (Step S1321).

The information relay apparatus that has received the transmissionresult of Step S1319 outputs the reception result to the log managementserver 101 (Step S1322), and the log management server 101 performs theprocessing of FIG. 7 to assign the signature to the log and archive thelog (Step S1323).

The third embodiment of this invention has been described above.

According to this embodiment, in view of a use case where the record ofthe processing relating to the information coordination is generatedeach time a communication occurs and the authenticity thereof needs tobe assured for a long term as the audit trail of the informationcoordination, a plurality of hash chains are formed by including aplurality of hash values of the log record positioned a plurality of logrecords before in all the log records in the digital signaturetechnology for the long-term assurance of the authenticity of the audittrail.

Therefore, even when a given log record has been tampered, theauthenticity of the other log records can be assured by another hashchain.

At this time, the number of verification steps for the digital signatureis reduced by efficiently performing the verification of the log recordpositioned a plurality of log records before, to thereby be able togenerate the log record while reducing the load on the computer imposedwhen the digital signature is generated.

Further, the hash chain for the log record positioned a plurality of logrecords before is created when the log record is generated, to therebyreduce the verification processing for the hash chain, and hence it ispossible to realize the high-speed verification of the specific data.

It should be noted that, in the example of this embodiment, thedescription has been made of an access token method for returninginformation coordination result from a machine of the informationproviding system to a machine of the information query system in StepS1309, but the authenticity of the audit trail of the informationcoordination can be maintained also in the information coordinationusing a gateway method for performing the information coordination fromthe machine of the information providing system to the machine of theinformation query system via the information coordination system.

With reference to FIG. 14 and FIG. 15, a description is made of anexample in which complexity is further enhanced when the hash chain isgenerated according to a fourth embodiment of this invention.

This embodiment is has a feature in that, in a case where a plurality ofaggregates of hash chains formed of a plurality of hash chains exist,the aggregates of hash chains are coupled by including, in the logrecord of a given aggregate of hash chains, a hash value of a log recordpositioned a plurality of log records before of the log record ofanother aggregate of hash chains.

The case where a plurality of aggregates of hash chains existrepresents, for example, a case where the aggregate of hash chains iscreated for each of the application servers 102. In other words, whenthe log record is generated from the log data output from theapplication server 1021, the hash value of the log record generated fromthe third previous log data of the application server 1021 and the hashvalue of the log record generated from the sixth previous log data ofthe application server 1021 are included to form the aggregate of hashchains of the application server 1021. As described above, a pluralityof aggregates of hash chains having the same number as the number ofapplication servers exist.

It should be noted that the description of this embodiment is directedto an exemplary case where two aggregate of hash chains exist (it isassumed that the aggregate of the application server 1021 is referred toas “aggregate s”, and the aggregate of the application server 1022 isreferred to as “aggregate t”).

In this embodiment, an improvement is made to the details (FIG. 5 andFIG. 6) of the log record generated by the generation method for the logrecord among the details of the first embodiment described withreference to FIG. 1 to FIG. 10, and the high-speed verification can beperformed by the processing described with reference to FIG. 8 and FIG.9, or in the second embodiment.

First, details of the log record are described with reference to FIG.14.

One log record 1401 of the aggregate s includes, in addition to thefields 502 to 510 illustrated in FIG. 5, an aggregate ID 1402 serving asa unique ID indicating the aggregate, a hash value 1403 of the thirdprevious log record of the aggregate t, an ID 1404 for concatenationserving as a unique ID indicating the hash value 1403 of the thirdprevious log record of the aggregate t, a hash value 1405 of the sixthprevious log record of the aggregate t, and an ID 1406 for concatenationserving as a unique ID indicating the hash value 1405 of the sixthprevious log record of the aggregate t. It should be noted that it isassumed that the ID for concatenation includes the ID of the aggregate,and can identify the aggregate. Further, a signature 1407 is a digitalsignature assigned to the fields 502 to 509 and 1402 to 1406 in the samemanner as the signature 510 illustrated in FIG. 5.

The signature generation part 203 of the log management server 101generates, from the log data received from the application server 1021,the hash values of the first previous, the third previous, and the sixthprevious log records of the aggregate of hash chains (aggregate s) ofthe application server 1021 in the same manner as in the firstembodiment. The signature generation part 203 further performs thearithmetic operation for the hash value 1403 of the third previous logrecord of the aggregate of hash chains (aggregate t) of the applicationserver 102 ₂, replicates the hash value of the sixth previous log recordof the aggregate t from the hash value of the third previous log recordof the aggregate t, and assigns the digital signature to the log record.Further, the signature generation part 203 assigns the ID forconcatenation to the first previous, the third previous, and the sixthprevious log records of the aggregate s and the third previous and thesixth previous log records of the aggregate t.

Next, FIG. 15 illustrates a structure 1501 of the hash chain forvisualizing the structure of the hash chain of the log recordexemplified in FIG. 14. As illustrated in FIG. 15, the log records ofthe aggregate s includes the hash values of the first previous, thethird previous, and the sixth previous log records of the own aggregateand the hash values of the third previous and the sixth previous logrecords of the aggregate t. As illustrated in FIG. 15, the chains (hashchains) of all the log records are formed respectively by the hashvalues of the first previous, the third previous, and the sixth previouslog records of the own aggregate and the hash values of the thirdprevious and the sixth previous log records of the aggregate t. In otherwords, the hash chains are also formed between the aggregate s and theaggregate t.

Normally, the hash chains generated by using the method illustrated inFIG. 14 and FIG. 15 are verified by the methods described in the firstembodiment and the second embodiment, but when no trust point exists inthe own aggregate due to a leak of the secret key caused by an attackeror the like, the verification is performed by tracing the hash chainthat links the trust point existing in another aggregate to theverification target.

The fourth embodiment has been described above. When this embodiment isapplied, the hash chain is generated between the own aggregate andanother aggregate. Therefore, the complexity of the chains is enhanced,which increases tolerance to attack. For example, even when thesignature becomes invalid due to a leak of the secret key correspondingto a given aggregate or the like, unless the signature of anotheraggregate becomes invalid, the verification can be performed by tracingthe hash chain from the another aggregate or the like.

It should be noted that the log record generated as a result of thisembodiment can also be applied to the high-speed verification accordingto the second embodiment and the information coordination systemaccording to the third embodiment.

Next, a configuration of a fifth embodiment of this invention isdescribed with reference to FIG. 16 to FIG. 18.

This fifth embodiment is has a feature in that, in the information querysystem, the information providing system, and the like that aredescribed in the third embodiment, instead of locating the respectivelog management servers, functions whose commonality can be achieved areshared as the log management server by a plurality of systems, and apart that cannot be shared is located in each system as a log managementclient. Specifically, the log management client has a function ofcalculating the hash value, and sends the hash value to the logmanagement server after calculating the hash value of the log data. Thelog management server assigns the signature to the hash value receivedfrom the log management client.

In this embodiment, the log is output at the timing described withreference to FIG. 13 in the third embodiment, the log record describedin the first embodiment and the fourth embodiment is generated, and thehigh-speed verification described in the first embodiment and the secondembodiment is performed.

FIG. 16 is a block diagram illustrating an example of a log managementsystem to which the fifth embodiment of this invention is applied. Thelog management system, the information query system, and the informationproviding system are coupled to one another through the network 103 suchas the Internet or a broadband WAN. The log management system includesthe log management server 101. The information query system and theinformation providing system include the information coordinationapparatus 1203 ₁ and 1203 _(N) (hereinafter referred to collectively as“information coordination apparatus 1203”) and log management clients1601 ₁ to 1601 _(N) (hereinafter referred to collectively as “logmanagement client 1601), and the information coordination apparatus 1203₁ and 1203 _(N) and the log management clients 1601 ₁ to 1601 _(N) arecoupled to each other through intra-organization networks 1205 ₁ to 1205_(N), respectively.

Next, the log management client 1601 is described with reference to FIG.17. FIG. 17 is a block diagram illustrating an example of functionalcomponents of the log management client 1601.

The log management client 1601 includes a processing part 1701 forcalculating the hash value of the log data from the log data sent fromthe information coordination apparatus 1203 and issuing a verificationrequest to the log management server, a storage part 1702 for storingthe log data or the like sent from the information coordinationapparatus 1203, an input/output part 1707 for receiving an input fromthe user or the administrator, and a communication part 1708 forreceiving the log data output from the information coordinationapparatus 1203.

The processing part 1701 includes a hash value generation part 1703 forgenerating the hash value of the log data, a signature verificationrequest part 1704 for issuing a verification request to the logmanagement server, and a control part 1705 for controlling those parts.

The storage part 1702 includes a log data holding part 1706 for storingthe log data.

The information query system or the information providing system thatuses the log management system sends each of the secret keys to the logmanagement system, and the log management system saves the secret keysto the secret key/certificate holding part 209.

It should be noted that the log management client 1601 exemplified inFIG. 17 can be realized by using such an apparatus as illustrated inFIG. 4 and programs or hardware having functions equivalent thereto inthe same manner as the log management server 101 and the applicationserver 102 according to the first embodiment.

Next, an example of log generation processing according to thisembodiment is described with reference to FIG. 18.

The information coordination apparatus 1203 transmits the log data tothe log management client 1601 at the timings of Steps 1302, 1310, 1312,1315, and 1320 (Step S1801). The log management client that has receivedthe log data saves the log data to the log data holding part 1706,generates the hash value of the log data by the hash value generationpart 1703 (Step S1802), and transmits the hash value of the log data tothe log management server (Step S1803).

The log management server 101 that has received the hash value of thelog data performs the processing of FIG. 6 to generate the signature tothe log (Step S1804) and archive the log (Step S1805), and returns theprocessing result (Step S1806). At this time, as described above, thelog management server assigns the signature to the hash value of the logdata sent from the log management client, and hence the log data withinthe log record 501 is H(M1), while the signature 510 isSign(H(M1)∥IV∥IV∥IV). Next, an example of log verification processingaccording to this embodiment is described with reference to FIG. 19.

The log management client 1601 acquires verification target log dataheld in the storage part 1702, generates the hash value of the log databy the hash value generation part 1703 (Step S1901), and transmits thehash value of the log data to the log management server (Step S1902).

The log management server that has received the hash value of the logdata searches for the log record including the log data by using thereceived hash value of the log data as a search key (Step S1903),performs the verification by performing the processing of FIG. 9 or FIG.11 for the retrieved log record (Step S1904), and returns theverification result to the log management client (Step S1905).

The log management client that has received the verification resultconfirms that the log data has not been tampered because the log recordincluding the transmitted hash value exists, and brings the verificationto an end.

The fifth embodiment has been described above. When this embodiment isapplied, in the third embodiment, it is possible to minimize cost on theinformation query system side or the information providing system sideand to assure the authenticity of the log data such as the record of theinformation coordination or the like.

At this time, on the log management client, the hash value of the logdata is calculated instead of the log data itself and transmitted to thelog management server, to thereby be able to reduce a load on thenetwork 103.

It should be noted that the log data may be transmitted to the logmanagement server and managed thereby when, for example, the network 103has sufficient performance.

Further, the log management system may perform nothing other than savingthe signature with the log management client having a function ofstoring the secret key and a function of generating signaturegeneration.

Further, in Step S1806, the log management server may return informationfor identifying the log record such as the data ID 503 or the aggregateID 1402 together to the log management client. In addition, the logmanagement server may use the information for identifying the log recordto perform a search.

As described above, this invention can be applied to the computer or thecomputer system for verifying data whose digital signature has an expiryperiod. In particular, it is preferred that the invention be applied tothe computer system for performing a hysteresis signature.

What is claimed is:
 1. A data authenticity assurance method carried outby a management computer comprising a processor and a memory,comprising: carrying out signature generation processing for generatinga second data piece by assigning a digital signature to data, which isobtained by combining a first data piece received from a computer with ahash value of at least one second data piece acquired from second datapieces held in a data holding part of the management computer, by usinga preset key, and holding the generated second data piece in the dataholding part; and carrying out signature verification processing forverifying authenticity by intermittently tracing a plurality of hashchains based on a plurality of second data pieces held in the dataholding part and the second data piece of a verification target,wherein: the carrying out of the signature generation processingcomprises: a first step of receiving the first data piece from thecomputer; a second step of selecting a plurality of second data piecesat predetermined intervals in chronological order from among positionedplurality of second data pieces before held in the data holding part; athird step of performing an arithmetic operation for each of the hashvalues of the selected plurality of second data pieces; a fourth step ofgenerating signature target data by combining the first data piecereceived from the computer with the hash values of the selectedplurality of second data pieces; and a fifth step of generating a seconddata piece by assigning the digital signature to the signature targetdata by using the preset key, and holding the generated second datapiece in chronological order sequentially in the data holding part; andthe carrying out of the signature verification processing comprises: asixth step of receiving the second data piece of the verificationtarget; a seventh step of acquiring a second data piece that isverifiable alone from the data holding part, and verifying the seconddata piece; and an eighth step of performing verification for the seconddata piece of the verification target to the second data piece that isverifiable alone by sequentially comparing a hash value obtained by thearithmetic operation from the second data piece with the positionedplurality of second data pieces before including the hash value, andperforming the verification by intermittently tracing the plurality ofhash chains.
 2. The data authenticity assurance method according toclaim 1, wherein the second step comprises selecting, by the managementcomputer, from the first previous second data piece and the(n×2^(p−1))th previous second data piece, the (N×2^(p−1)) being ageneral term serving as a geometric progression of a first term of N anda common ratio of 2, when the at least one second data piece is selectedat the predetermined intervals in chronological order.
 3. The dataauthenticity assurance method according to claim 1, wherein the thirdstep comprises acquiring, by the management computer, instead ofperforming the arithmetic operation for each of the hash values of theplurality of second data pieces, another second data piece including thehash value of the second data piece of an arithmetic operation targetfrom the data holding part, and replicating and acquiring the hash valueof the second data piece of the arithmetic operation target from theacquired another second data piece.
 4. The data authenticity assurancemethod according to claim 1, wherein: the third step comprises a ninthstep of examining the authenticity of each of the plurality of seconddata pieces; and the ninth step comprises executing the sixth step tothe eighth step with each of the plurality of second data pieces set asthe verification target.
 5. The data authenticity assurance methodaccording to claim 1, wherein the eighth step comprises continuing theverification by acquiring another second data piece including the hashvalue from the data holding part and setting the another second datapiece as a comparison target in one of: a case where the hash valueobtained by the arithmetic operation from the second data piece does notmatch the second data piece including the hash value; and a case wherethe second data piece does not exist, when comparison is sequentiallyperformed for the second data piece of the verification target to thesecond data piece that is verifiable alone.
 6. The data authenticityassurance method according to claim 1, wherein the seventh stepcomprises selecting the second data piece that is verifiable alone,which has a minimum number of times that the plurality of hash chainsare intermittently traced, from among a plurality of second data piecesthat can is verifiable alone when the second data piece that isverifiable alone is selected.
 7. The data authenticity assurance methodaccording to claim 1, wherein the eighth step comprises presenting allthe second data pieces used for the verification when the plurality ofhash chains are intermittently traced, to a user of the managementcomputer.
 8. The data authenticity assurance method according to claim1, wherein: the management computer comprises the computer to form arelay system; the relay system is coupled to a plurality of processingsystems comprising the computer; and the data authenticity assurancemethod further comprises generating, when a third data piece comprisingelectronic data is transmitted from one processing system to anotherprocessing system among the plurality of processing systems via therelay system, by the computer forming the relay system, a record ofprocessing transmitted from a processing system comprising the thirddata piece to another processing system as the first data piece, andtransmitting the record to the management computer forming the relaysystem.
 9. The data authenticity assurance method according to claim 1,wherein: the management computer is coupled to a plurality of computers;the first step comprises identifying which computer among the pluralityof computers the first data piece has been received from; the secondstep comprises managing/holding, by the management computer, when theplurality of second data pieces are selected at the predeterminedintervals in chronological order, the plurality of second data piecesheld in the data holding part for each of the plurality of computers,and selecting the second data piece separately managed/held so as tocorrespond to the computer identified in the first step; and the fifthstep comprises managing/holding, by the management computer, when thegenerated second data pieces are held in chronological ordersequentially in the data holding part, the generated second data piecesseparately for each of the plurality of computers, to thereby form eachof the plurality of hash chains for each of the plurality of computers.10. The data authenticity assurance method according to claim 9, whereinthe second step further comprises selecting, by the management computer,when the plurality of second data pieces are selected at thepredetermined intervals in chronological order, the second data piecemanaged/held so as to correspond to the computer identified in the firststep and the second data piece managed/held so as to correspond to thecomputer other than the identified computer from the chronological-ordersecond data pieces managed/held for each of the plurality of computersin the fifth step.
 11. The data authenticity assurance method accordingto claim 1, wherein: the first step comprises calculating, by thecomputer, hash data of a fourth data piece held in the computer, holdingthe fourth data piece in the data holding part of the computer,transmitting the hash data to the management computer, and receiving, bythe management computer, the hash data as the first data piece; and thesixth step comprises acquiring, by the computer, the fourth data pieceof a verification target from the data holding part, calculating thehash data of the acquired fourth data piece, transmitting the hash datato the management computer, and receiving, by the management computer,the hash data as the first data piece.
 12. A management computer,comprising: a hardware processor; a memory; and a controller forcarrying out: signature generation processing for generating a seconddata piece by assigning a digital signature to data, which is obtainedby combining a first data piece received from a computer with a hashvalue of at least one second data piece acquired from second data piecesheld in a data holding part of the management computer, by using apreset key, and holding the generated second data piece in the dataholding part; and signature verification processing for verifyingauthenticity by intermittently tracing a plurality of hash chains basedon a plurality of second data pieces held in the data holding part andthe second data piece of a verification target, wherein: the controlleris configured to, in the signature generation processing: receive thefirst data piece from the computer; select a plurality of second datapieces at predetermined intervals in chronological order from amongpositioned plurality of second data pieces before held in the dataholding part; perform an arithmetic operation for each of the hashvalues of the selected plurality of second data pieces; generatesignature target data by combining the first data piece received fromthe computer with the hash values of the selected plurality of seconddata pieces; and generate a second data piece by assigning the digitalsignature to the signature target data by using the preset key, and holdthe generated second data piece in chronological order sequentially inthe data holding part; and the controller is further configured to, inthe signature verification processing: receive the second data piece ofthe verification target; acquire a second data piece that is verifiablealone from the data holding part, and verifying the second data piece;and perform verification for the second data piece of the verificationtarget to the second data piece that is verifiable alone by sequentiallycomparing a hash value obtained by the arithmetic operation from thesecond data piece with the positioned plurality of second data piecesbefore including the hash value, and perform the verification byintermittently tracing the plurality of hash chains.
 13. Acomputer-readable non-transitory storage medium having stored thereon adata authenticity assurance program executed by a computer comprising aprocessor and a memory, the data authenticity assurance programcontrolling the computer to execute: signature generation processing forgenerating a second data piece by assigning a digital signature to data,which is obtained by combining a first data piece received from acomputer with a hash value of at least one second data piece acquiredfrom second data pieces held in a data holding part of a managementcomputer, by using a preset key, and holding the generated second datapiece in the data holding part; and signature verification processingfor verifying authenticity by intermittently tracing a plurality of hashchains based on a plurality of second data pieces held in the dataholding part and the second data piece of a verification target,wherein: the executing of the signature generation processing comprises:a procedure for receiving the first data piece from the computer; aprocedure for selecting a plurality of second data pieces atpredetermined intervals in chronological order from among positionedplurality of second data pieces before held in the data holding part; aprocedure for performing an arithmetic operation for each of the hashvalues of the selected plurality of second data pieces; a procedure forgenerating signature target data by combining the first data piecereceived from the computer with the hash values of the selectedplurality of second data pieces; and a procedure for generating a seconddata piece by assigning the digital signature to the signature targetdata by using the preset key, and holding the generated second datapiece in chronological order sequentially in the data holding part; andthe executing of the signature verification processing comprises: aprocedure for receiving the second data piece of the verificationtarget; a procedure for acquiring a second data piece that is verifiablealone from the data holding part, and verifying the second data piece;and a procedure for performing verification for the second data piece ofthe verification target to the second data piece that is verifiablealone by sequentially comparing a hash value obtained by the arithmeticoperation from the second data piece with the positioned plurality ofsecond data pieces before including the hash value, and performing theverification by intermittently tracing the plurality of hash chains.